Tips & techniques for Users of Sunsoft Solaris
Do you have a server daemon you'd like to run at bootup on your Solaris 2.x machine? In earlier versions of Solaris, you could configure daemons to run on bootup in the /etc/rc or /etc/rc.local files. With Solaris 2.x, the /etc/rc and /etc/rc.local files have been incorporated into init and the files it uses to call other programs. The principal file that init uses to call other programs is /etc/inittab. In this article, we'll take a look at init and show you how to configure /etc/inittab to load a server daemon on system bootup.
Before we demonstrate how to configure your Solaris system with custom boot parameters, it's a good idea to have a basic understanding of the files you'll be dealing with when you add these parameters. Each time your Solaris system boots, the init process controls the overall state of the system and creates processes using information stored in the /etc/inittab file.
Your system at any given time operates under one of eight different run levels. A run level is a software configuration under which only a selected group of processes can exist. Processes spawned by init during each of these run levels are defined in the /etc/inittab file. To get a better feel for your Solaris system run levels, let's define them. In Table A, you'll find the eight different run levels under which your system can operate.
Run level
0 This run level initiates your system firmware (when applicable).
1 This run level puts your system in ad-ministration mode. All file systems are mounted and only a small set of kernel processes are left running. This run level is used mainly for administrative tasks such as installing additional utility packages. All files are accessible and no users can log onto the system.
2 This run level puts the system in multi-user mode. All multi-user environment terminal processes and daemons are spawned in this run level. Most configuration daemons are launched in this level.
3 This run level starts the remote file-sharing processes and daemons. All remote resources mount during this run level, which is considered as a multi-user extension of run level 2.
4 This run level isn't necessary for system operation and can be defined as an alternative multi-user environment configuration.
5 This run level creates a system state in which it's safe to remove power from the system.
6 This run level stops the operating system and reboots to the state defined by the initdefault setting in the /etc/inittab file.
S, s This run level puts the system in single-user mode. When this occurs, the terminal that executes the init command becomes the system console (provided the user has the proper permissions). This is the only run level that doesn't require the existence of a properly formatted /etc/inittab file. If an /etc/inittab file doesn't exist, then single-user mode is the only run level init can enter. When booted in single-user mode, file systems for users' files aren't mounted and only essential processes run. When the system exits multi-user mode (run level 2) and enters single-user mode (run level S), all mounted file systems remain mounted and any multi-user processes are terminated.
When your system boots, init launches and the following procedures occur: First, init reads the /etc/default/init file to set your system environment variables. Next, init looks in /etc/inittab for the initdefault setting. If the setting exists, init initiates the run level specified. If no initdefault setting exists, init prompts the user to enter the desired run level from the system console.
If this is the first time since you powered up your system that init has entered a run level other than the single-user state, init scans the /etc/inittab file for boot and bootwait entries. These entries execute before any other processing of /etc/inittab, provided that the run level matches the entry. This allows for special initialization of the Solaris operating system, such as mounting file systems, before any users can access the system. Once the boot and bootwait entries complete, the init process scans and launches the rest of /etc/inittab.
To spawn an entry in the /etc/inittab file, init reads each entry; for each entry that needs to be spawned, it forks a child process. After it spawns all of the processes specified by /etc/inittab, init then waits for one of its descendant processes to die, a powerfail signal, or a signal from another init process to change the system's run level. When this occurs, init re-examines the parameters in /etc/inittab.
When init receives the signal that a process it spawned has died, it records the termination occurrence and the reason in the /var/adm/utmp file where a complete history of processes spawned by init is kept in the /var/adm/wtmp file.
If init receives the powerfail signal, SIGPWR, it scans /etc/inittab for any special entries with powerfail or powerwait settings. These entries are launched before any further processing takes place. This provides init with the ability to perform any cleanup and recording functions while Solaris powers down.
If init receives a run-level change request, it will send a warning signal, SIGTERM, to all processes not defined in the new run level. After waiting five seconds, init will terminate these processes by sending the kill signal, SIGKILL.
In Figure A, you can see the Solaris default /etc/inittab file. Each entry in the /etc/inittab file follows the format
id:rstate:action:process
The id field consists of one or two characters used for identification purposes. The rstate field defines the run-level state for each entry in /etc/inittab. If, for example, your system boots at run level 3, then init processes only those entries in your /etc/inittab file with an rstate field value of 3. When you make a run-level change request, those processes whose entries in /etc/inittab have an rstate value equal to the current run level are sent the warning signal SIGTERM before being terminated with SIGKILL.
In addition to the eight run levels, the rstate field can also contain the values a, b, or c. Entries with these rstate values can only run when specifically requested to do so by init. A request to run such an entry in /etc/inittab won't change the current run level of your system. In addition, any processes whose rstate value is a, b, or c won't be killed if the system changes run levels. These processes can only be killed if
or
The action field in an entry in /etc/inittab uses keywords to tell init how to handle the process in the process field. The keywords, defined in Table B, are the only valid entries for the action field.
Keyword/Action
respawn If the process doesn't exist in the current list of processes already running, then start the process and don't wait for its termination. If the process already exists, do nothing and continue processing /etc/inittab.
wait When init enters a run level that matches the rstate field, run the process and wait for its termination. If init stays in the same run level, all subsequent reads of /etc/inittab ignore this entry.
once When init enters a run level that matches the rstate field, run the process and don't wait for its termination. When the process dies, don't restart it. Run-level changes won't restart the process if it has already run previously.
boot Process the entry only at init's boot-time reading of the /etc/inittab file. The process won't restart when it dies and init won't wait for its termination. The rstate value should always match the run level of init at boot-time.
bootwait Process the entry the first time init goes from single-user to multi-user mode after the system boots. The process starts and init waits for its termination. When the process dies, init won't restart it.
powerfail Execute this process only when init receives a powerfail signal, SIGPWR.
Keyword/Action
powerwait Execute this process only when init receives a powerfail signal, SIGPWR, and wait until it terminates before continuing to process /etc/inittab.
off If the process is currently running, send a SIGTERM warning before sending SIGKILL to terminate the process. If the process isn't running, ignore the entry.
ondemand Synonymous with the respawn action, this action is used with entries that have rstate values of a, b, or c. This removes the process from any run-level changes that would affect it otherwise.
initdefault An entry with this action reads only when init runs initially at bootup. The rstate field determines which run level init will enter. If the rstate field is empty, init will loop into rebooting continuously. If no entry in /etc/inittab contains the initdefault action, init will request a run level from the system user.
sysinit Actions of this type execute before init tries to access the console. This entry is used only to initialize devices that init will try to ask the run level question to. These entries execute and init waits for their completion before terminating.
The process field contains the name of the process you intend to run. Be sure that any process defined in this field has the appropriate file permissions for execution. Now that we've defined the entries in /etc/inittab, we'll add a new boot parameter and show you how to make it work.
You can add entries to /etc/inittab at any time. Since we'll be adding boot parameters to /etc/inittab, we recommend rebooting your system to test your additions to the /etc/inittab file. As shown in Figure A, the default run level of 3 for init is defined by the entry
is:3:initdefault:
As you'll remember, run level 3 begins remote sharing of your Solaris system in multi-user mode. If you want your boot parameter to load for this run level, you can add the following line to your /etc/inittab:
i1:3:respawn:/usr/home/program_name
This entry in your /etc/inittab will run your program each time your system boots and will respawn the program if the process dies.
If a boot parameter you'd like to add to your system is a maintenance program and you want it to execute only at system bootup and then terminate, use the action keyword wait like this:
i1:3:wait:/usr/home/program_name
Init will execute your program once upon entering run level 3 and then wait for the process to terminate. Any subsequent scans of /etc/inittab while your system remains in the same run level will ignore this entry.
In the default /etc/inittab file in Figure A, you'll see an entry that begins
s3:3:wait:/sbin/rc3
This line executes the script file /sbin/rc3, shown in Figure B, which launches several programs when the system enters run level 3. If you like, you can add your boot parameters to this script file to run it on system bootup.
As you can see, you have many options when you want to configure boot parameters for your Solaris system using the /etc/inittab file and init. In this article, we've explained how init launches processes using /etc/inittab and demonstrated how to configure your own boot parameters with /etc/inittab. v
[Return to Index for Inside Solaris - October Issue]
Copyright (c) 1995 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis
Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of
Ziff-Davis Publishing Company.
